ルーチンワークをフローのきっかけに

ソフトウェア・エンジニアやプログラマはよくアーティストに例えられます。ある人は2時間だけのコーディングで、他の人の8時間分の成果をあげることができます。また、コードの長さは必ずしもその品質やデザインの美しさ、メンテナンス性の高きには比例しません。あるプログラマが朝9時に出社し、夕方6時に退社するとしても、その問ランチをのぞいた8時間、つねにターミナルやエディタを開いてコーディングしつづける、というのはむしろ稀な部類でしょう。

周りの妨げがなくコーディングに没頭している状態を「フロー状態」と呼びますが、このフロー状態に何の苦労もなく突入できるエンジニアを本当の達人プログラマと呼ぶのかもしれません。何しろ、フローに入るための邪魔や誘惑が多すぎます。受信箱にたまった未読メール、RSSフィードリーダーにたまったニュース、頻繁にポップアップするメッセンジャーやIRCチャット。そして12時になれば同僚とのランチ、午後3時には多少の眠気とたたかうためのコーヒー。

こうした誘惑に打ち勝つて、ついにエディタやターミナルを開いても、そこからいきなりコードを書き始める、というのもなかなか難しいものです。どんな運動でも準備運動や助走が必要なように、コードを書くという(クリエイティブな!)作業の前にも、そのための準備が必要です。この準備はどんなものでもいいのですが、「ルーチンワーク」をこの準備として利用すると便利なことがあります。

2年ほど前の話ですが、私の参加するプロジェクトでは、常時2本以上の開発ブランチが定り、また2週間に1度はそれをマージしてプロダクション環境にリリースする、という開発形態をとっていました。それぞれのブランチで複数人が日々多数のコミットを行っており、2週間に1度だけのマージでは発生するコンフリクトの数が多すぎるという問題がありました。そこで、次回リリース用のプランチを用意し、開発プランチから毎日マージすることで、コンフリクトの影響を最小にし、また継続インテグレーションによるテストを容易にしよう、ということになりました。

半年ほど、私がそのマージの担当者となっていた時期がありました。その問、出社して最初にすることは、ターミナルを開き、開発用サーバにログインして各ブランチからリリースブランチへマージを行うという、いわば単純作業です。もちろんシェルスクリプトを書いてある程度の作業は自動化しましたが、コンフリクトが発生したときの確認や、最後にコミットしてレポジトリにプッシュする部分はターミナルで行います。はじめの数日間は、「こんなルーチンワーク、退屈だな。早く自分の担当がおわればいいけど」と考えていましたが、その作業を続けるうちに、それが毎朝、自分の環境でターミナルを開いて、次に来るべきコーディングへの準備になっていることに気づきました。非クリエイティブにも見えるルーチンワークで自分の体や思考パターンを慣らして、かっその作業をしている間はメールなどの誘惑からも自然とシャットアウトし、フロー状態にはいる助走ができているわけです。

現在ではその日々のマージ作業はバージョン管理ツールの変更や開発形態が変わったことにより、必要なくなりましたが、こうしたルーチンワークを1日の最初に行う余地を残しておくことは有用だと思っています。毎日のルーチン作業ではなくても、1日の終わりに、翌日最初に行うことを決めてメモしておく、とか、あるいはふと思いついた変更のアイディアをコードのコメントとして残しておく、とか。あえて一晩寝かせておくことで、そのアイデアがいいものであるのか、あるいはあまり筋が良くないものであるか、気づくこともあるかもしれません。

ルーチンワークで時間を無駄にするのはよくないことです。自動化することによって時間やコストを節約し、またマニュアル作業によるミスを減らすことも重要でしょう。ただ、ほんの少しだけ、その作業で手や頭を動かす余地を残しておくのも、プログラマがクリエイティブになる準備としては、悪くないのかもしれません。